IBIS Macromodel Task Group

Meeting date: 15 December 2015

Members (asterisk for those attending):
ANSYS:                      * Dan Dvorscak
                            * Curtis Clark
Avago (LSI):                  Xingdong Dai
                              Bob Miller
Cadence Design Systems:       Ambrish Varma
                              Brad Brim
                              Kumar Keshavan
                              Ken Willis
Cisco:                        Seungyong (Brian) Baek
eASIC:                        David Banas
                              Marc Kowalski
Ericsson:                     Anders Ekholm
GlobalFoundries:              Steve Parker
Intel:                      * Michael Mirmak
Keysight Technologies:        Fangyi Rao
                            * Radek Biernacki
Maxim Integrated Products:    Hassan Rafat
Mentor Graphics:            * John Angulo
                            * Arpad Muranyi
Micron Technology:          * Randy Wolff
                              Justin Butterfield
QLogic Corp.:                 James Zhou
                              Andy Joy
SiSoft:                       Walter Katz
                              Todd Westerhoff
                            * Mike LaBonte
Synopsys:                     Rita Horner
Teraspeed Consulting Group:   Scott McMorrow
Teraspeed Labs:             * Bob Ross
TI:                           Alfred Chong


The meeting was led by Arpad Muranyi.

--------------------------------------------------------------------------------
Opens:

- Arpad reminded everyone that meetings on December 22nd and 29th were
  cancelled, as was the meeting on January 19th because DesignCon and
  the associated IBIS summit occur that week.
  
- Mike L. asked if there would be an ATM task group report at the DesignCon IBIS
  summit.  Arpad stated that he would draft the report, and someone else could
  present it if he were unable to attend the summit.

--------------------------
Call for patent disclosure:

- None.

-------------
Review of ARs:

- None.

-------------------------
Review of Meeting Minutes:

- Arpad: Does anyone have any comments or corrections? [none]
- Mike L.: Motion to approve the minutes.
- Arpad: Second.
- Arpad: Anyone opposed?  [none]

-------------
New Discussion:
  
Discussion of language corrections regarding "ground":
- Arpad: [Sharing Walter's proposed new paragraph on the screen]
  - New paragraph:
    "GND is used in many places in this document as the signal_name of Pins that
    have Model Name GND. GND in many "buffer example schematics" use this name
    GND as a signal name such as VCC, VDD, VSS. The string GND in this document
    shall refer to either a Model Name in the Pin list or a signal name on one
    or more pins that coincidently also have Model Name GND. GND shall never be
    interpreted as the reference node in many SPICE simulators that is often
    called Node 0. Since IBIS defines signal_name as a component Data Book Name,
    we must assume that all Pins that have Model Name POWER or GND and have the
    same signal_name are assumed to be connected together on the components
    board or module. Each buffer can have one or two ground terminals (pdref
    and/or gcref) that are local nodes of the of the power distribution circuit
    of Pins that has Model Name GND. [Pin Mapping] is required to determine
    which signal_name is the local ground nodes of each Buffer."
- Bob: My issue is that adding this definition under section 3 goes too far.
  - It introduces new restrictions that don't exist in IBIS.
  - It documents rules with respect to keywords, terminals, etc., that aren't
    defined at that point, and makes forward references to things throughout a
    240 page document.
  - Listing what can be done with "GND" excludes some things that are done now.
  - For example: While the original intent of IBIS was perhaps that "GND" was a
    reserved model name, and you could do anything with signal name (we made the
    suggestion they comply with data book names), it turns out that since
    ibischk2 you can use "GND" or any of the five other reserved names as
    [Pin Numbers] if you want.  Perhaps this was unintentional, because it was
    flagged as an error in ibischk1.  But, I don't propose changing it.  There
    might be a good reason to call a specific pin GND because it's your ground
    plane pin.
- Radek: So you are saying the pin name can be called GND?
- Bob: Yes, or NC or anything and it will pass the parser after ibischk2.
- Radek: That's inconsistent with the opening statement that they shouldn't be
         used for other purposes.
  - That can be rectified.
- Bob: That's why I didn't want to go too far down that path here.
  - For example, it could also be used as a node name in multilingual.
  - It would be a 50 page document to enumerate where it can and can't be used.
  - Making an overly restrictive generalization here opens up trouble.
- Arpad: Would it help if we took Walter's paragraph and started by marking it
         up sentence by sentence as to whether we agree or disagree?
  - Then if we disagree we have to fix something.
- Michael M.: We want to agree on the objective of the paragraph.
  - Is the object to permanently disassociate "GND" and node 0?
- Arpad: I think another motivation on Walter's part is to associate a
         connectivity meaning with the signal name column.
  - In other words, signal name is not just a meaningless column containing data
    book names.  There are connectivity assumptions based on the names.
- Radek: As far as I recall, we really don't have an association of "GND" with
         node 0 in the spec, except for one particular statement we can modify.
  - On the other hand, we have to clearly define what "GND" is.
  - We need to have the GND node clarified 100%.
  - Whether it is node "GND" or we call it the "reference node for the I/O port"
    we have to have it properly defined.
- Bob: It's referred to as a model name, and you mention it could be used as a
       local reference, and not necessarily a global reference such as would
       exist as node 0 in SPICE.
  - I think that's as far as we should go in defining it there.
  - It may be used as a signal name and unless explicitly stated in other areas.
- Arpad: From an IC perspective:
  - GND on an IC can only, at best, be the silicon substrate on the die.
  - From a Buffer [Model]'s perspective GND at best could be the die substrate.
  - But it doesn't always have to be, it could be -15V or something else.
  - The main point is that we really don't have a node 0 type ground on the die.
- Bob: In many SPICEs, I think use of "GND" is interpreted as global ground.
- Arpad/Radek: That's correct.
- Radek: We need to clearly disassociate ourselves from those concepts.
  - But we still need to have the local ground properly defined.
  - The signal (input or output), it's a port concept and we need to have two
    nodes clearly defined.  Whether that's the substrate or whatever, is up to
    the model maker but there must be a way to indicate what it is and to
    connect to it, including for packages and interconnect models.
- Arpad: The IC comment was just the first half of my thought:
  - From a buffer's perspective on the silicon we are pretty clear, we just have
    to define what pad the substrate is connected to and how the pad goes out to
    the pin.
  - But when it comes to the package and transmission line type models I think
    the problem gets more complex.  In a w-element type environment we have the
    "reference node", and that reference node is not supposed to be used to
    model a ground plane or anything carrying non-ideal currents or voltages.
    But even then the reference node has to be there for numerical purposes.
    What do we do with that?
- Radek: It has to be clearly defined.
  - We have to make the connections properly.
- Arpad: If you have a package model with w-elements that has signal and power
         and ground traces, a w-element signal terminal will be used for the
         ground traces as well.  But the w-element that carries the ground still
         has a reference node.  Where does that go?
- Radek: It goes to whatever is the reference node.  If that's local ground it
         goes to local ground, but we have to know what it is.
  - If you have two traces and you consider another substrate as the local
    ground, then you have two transmission lines so the w-element has two traces
    and six connection pins.  Preferably the reference node is the same for both
    ends because we don't have enough information for different reference nodes.
- Discussion: As fodder for a thought experiment, Arpad proposed an example with
  a buffer containing only power, signal, and ground terminals.  Therefore, it
  has a die with 3 pads and a package with 3 pins.  Arpad and Radek had
  differing opinions on how this would be modeled.  Arpad suggested that to get
  from the board-side of the package to the die-side one would model a 3
  conductor w-element, with one conductor each for power, signal and ground.  He
  said that 3 conductor w-element would still have a fourth reference node (or
  possibly a fifth if a reference node were specified on each end), and that
  this ideal reference node had nothing to do with the ground pin or ground
  pad on the die.  All 3 conductors would appear in the [Package Model]
  matrices.  Radek countered that if the ground pin provided the local ground
  then it should be the reference node.  He stated Arpad's example would be
  modeled as two traces (power and signal) with ground serving as the local
  reference.  You would therefore have two ports on each end.  Two traces and
  the local ground or substrate would form two coupled transmission lines.  Only 
  the signal and power pins would appear in the [Package Model] matrices.
- Arpad [sharing the IBIS-ISS spec's W-element syntax description, and noting:
         i1 i2 ... in ir o1 o2 ... on or]
- Discussion: Arpad referred to his example and suggested it would be modeled
  with i1 i2 i3 and o1 o2 o3 as the input and output terminals of the 3
  conductors (power, signal, ground) and that the ir and or were the ideal
  reference terminals.  Radek again countered with an s-element
  type port concept and said that the ground conductor would serve as the local
  reference ir and or, and that it would not itself appear in the [Package
  Model] matrices.  Bob pointed out that it was a "reference conductor" from
  ir to or, so they couldn't be arbitrary reference nodes at different voltages.   
  Arpad, however, noted that years ago he could not put two different DC sources
  on the ir and or.  But more recently, however, SPICE simulators allowed him to
  do it.  Radek said that in general it did not make much sense to have two
  separate ir and or nodes, but that it is available, and it is also true that
  some simulators allow per port references for s-parameters.  It's generally
  best for circuit simulation for ir and or to be the same node.  Arpad worried
  that losses through the ground trace would not be modeled if it's the
  reference.  Radek suggested a losses through the whole loop approach.
- Arpad: Isn't this ground reference question central to Walter's paragraph.
- Bob: I think Walter's GND statement is just with respect to buffer models.
  - You need the interconnect spec for transmission lines.
  - We've dealt with it there, where you bring out a reference line.
- Radek: All you have for the [Component] is the external [Pin]s.
- Arpad: We're relatively well defined with reference terminals on the die.
  - What happens though, when you start putting W-elements in the package and
    on the die?
- Radek: In the [Pin Mapping] we really need a local ground entry.
  - We have pullup_ref, pulldown_ref, etc., even the rarely used ext_ref.
  - We don't have a local ground specified.  That would be the reference we are
    talking about.
- Bob: That's what Walter is proposing, that we define pulldown_ref or gnd_clamp
       ref as the local ground.
- Radek: If there's no conflict with other issues (like -15V).
- Arpad: That's why I'm not sure if that solution would work.
- Bob: Plus it's confusing, and C_comp to local ground would not resolve the
       power-aware IBIS issues any better than C_comp to node 0.  You need to
       split up C_comp to distribute it to achieve that.
  - And as Arpad said, sometimes any terminal can be the local ground.
  - We've just seen an example on the reflector from a model maker.  The input
    swings from 0 to 3v, but the output swings from 9.9 to -6.6.  The output
    doesn't technically have a local ground terminal.  All of the numbers in
    the model are multiples of 3.3v.  It's got an internal voltage multiplier as 
    its reference.  The reference terminals aren't even attached externally.
- Radek: Additionally, if you have a pseudo-differential buffer consisting of
         two single ended buffers, how do you connect them?
  - We simply need those nodes.
- Bob: In our early days the thinking was that global node 0 was as good as any.
- Radek: But the idea is that node was there from the beginning. It was just
         assumed to be node zero.  Now we want to call it "GND" and say it is
         not necessarily node 0, but the node was there from the beginning.
- Discussion: Arpad asked if Randy would be willing to weigh in on the topic
  since Micron develops high quality package models and IBIS models in general.
  Randy mentioned that Curtis had recently been asking him similar reference
  related questions about package models.  Randy said that when simulating a
  package substrate, their package modeling tools require the definition of
  a ground reference for that simulation.  In the 2.5 or 3D field solver one
  might define that at infinity, but they usually define a reference plane by
  defining a metal structure some distance below the package substrate.  When
  that package is solved, ground traces or planes within the package are defined
  as though they are signals, not used as any sort of reference.  When you
  get the data out of the package simulator you have capacitance not only from a
  particular signal to your ground trace, but also from that signal to your
  external reference, which is more like node zero.  Randy acknowledged that
  when many tools output a SPICE sub circuit for the package model, they have
  a ground node for the actual ground trace but end up using node 0 inside the
  sub circuit to serve as the external reference.  He said that how to deal with
  that and avoid the implicit connection to node zero was on open question for
  us.  Radek expressed his concern that without giving the IBIS user more
  information about the external reference node they had insufficient
  information, and we were left with no choice but to use node 0.  He suggested
  that one of the actual ground traces should be defined as the reference.
  Arpad asked whether the capacitances with respect to the external reference
  node were significant in value or perhaps negligible.  Randy said that it
  depended upon the structure of the package and that, for example, a structure
  with a single layer and no ground plane might show significant coupling between
  a signal and the external reference layer.  Arpad said that with a far away
  reference he would expect the terms to be very small, but it sounded like
  Randy's simulations needed to use a closer reference.  Randy said that they
  tend to model their packages using a reference plane just below the solder
  balls because that's the closest description of the way the package is
  actually attached to a real circuit board.  He said this placement tended to
  give them simulations with the best correlation with measured data.
- Arpad: We've talked a lot, but I'm not sure if we are making progress.
- Discussion: Mike L. noted that we started with the goal of going over Walter's
  paragraph, and then the question was raised about the whether we all agreed on
  the objective of the paragraph.  Mike said that he felt Walter's initial
  statement on "GND" read more like a style guide, or upfront warning to the
  user that they might encounter "GND" as a model name or a signal name.  He
  said that the spec actually used GND as a signal name in relatively few
  places, and that we might be able to remove those uses from the spec by
  simply renaming things where GND had been used as a signal name.  He said this
  would eliminate confusion in the spec and obviate the need for Walter's
  statement.  Arpad and Bob objected to this idea.  Neither felt that it was
  necessary to alter the way GND had been used in the spec.  Bob felt that since
  it was legal to have GND as a signal name, perhaps if a data book name really
  was GND, we should not attempt to remove such usage from the spec.  Arpad felt
  that we could simply clarify the meaning in each instance where GND was used
  in the spec.  Radek pointed out that the interconnect proposal went in that
  direction and designated whether something was a pin name, signal name, etc.
- Mike L: [sharing IBIS 6.1, Section 6.1, page 33, paragraph 2]
- Discussion: Mike L. pointed out that this paragraph, which describes how the
  capacitors related to C_comp_xxx values are connected, uses GND in the context
  of a ground node.  He felt this hadn't been properly defined.  Bob agreed and
  said that it should be "local ground reference" in a rewrite.  Michael M. was
  even more critical of the last sentence.  He said we already overloaded the
  four [Pullup Reference], [Pulldown Reference], [POWER Clam Reference], [GND
  Clamp Reference] keywords in the sense that they could be values or reference
  nodes, and pointed out that this paragraph strongly implied that [Voltage
  Range] itself was some sort of power rail instead of just a value representing
  the potential difference between two particular nodes.  Everyone agreed that
  this paragraph will need to be rewritten.
- Arpad: It seems that Walter's proposal was an attempt to define a general rule
         at the outset that could allow us to resolve many issues with one
         statement.
  - I'm beginning to wonder if it is going to work that way.
  - Perhaps we would be better off to start reading the document sentence by
    sentence and hashing out the details for each necessary change.  Then, as we
    are doing that, if we run into something that could be generalized up front
    we can add an upfront statement.
  - Right now it seems that we've spent two meetings trying to tackle the
    generalized concept and still have confusion and or disagreement.
- Mike L.: I was thinking the same thing.
- Arpad: With that let's close the meeting today.
  - Thank you all for the good work in 2015.  Happy Holidays and Happy New Year.

-------------
Next meeting: 05 January 2016 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
